home *** CD-ROM | disk | FTP | other *** search
/ Software of the Month Club 2000 October / Software of the Month - Ultimate Collection Shareware 277.iso / pc / PROGRAMS / UTILITY / WINLINUX / DATA1.CAB / programs_-_usrdoc / PROCMAIL.{23 / FAQ.{__ < prev    next >
Encoding:
Text File  |  1999-09-17  |  13.1 KB  |  296 lines
  1. ------------------------------------------------------------------------------
  2. ---------------------- Frequently Asked Questions ----------------------------
  3. ------------------------------------------------------------------------------
  4.  
  5. 1. How do I go about setting up a mailinglist or a mail-archive server?
  6.  
  7.     Look in the SmartList directory, start reading the INTRO file,
  8.     it describes it in detail and should get you started.
  9.  
  10. 2. I installed procmail (i.e. typed 'make install'), but how am I supposed to
  11.    use it?  When I type procmail on the command line it simply does nothing.
  12.  
  13.     ***********************************************************************
  14.     There exists an excellent newbie FAQ about mailfilters (and procmail
  15.     in particular), it is being maintained by Nancy McGough <nancym@ii.com>
  16.     and can be obtained via:
  17.  
  18.     World Wide Web (the nicest format for online reading!):
  19.     http://www.faqs.org/faqs/mail/filtering-faq/
  20.  
  21.     Anonymous FTP:
  22.     ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/filtering-faq
  23.  
  24.     E-mail:
  25.     Send mail to mail-server@rtfm.mit.edu containing the following:
  26.         send usenet/news.answers/mail/filtering-faq
  27.  
  28.     UUCP:
  29.     uunet!/archive/usenet/news.answers/mail/filtering-faq
  30.  
  31.     It is also posted monthly in at least the following newsgroups:
  32.         comp.mail.misc, comp.answers, news.answers
  33.     ***********************************************************************
  34.  
  35.     You're not supposed to start procmail from the command line.
  36.     Procmail expects exactly one mail message to be presented to it
  37.     on its stdin.  Usually the mail system feeds it into procmail.
  38.     If you start it by hand, you have to type the mail.
  39.  
  40.     Be sure to have a .forward and a .procmailrc file in your home
  41.     directory (see the examples subdirectory or the man page).
  42.     MMDF users should note that they need a .maildelivery file *instead*
  43.     of a .forward file (see the man page for more detailed information).
  44.  
  45.     If however, procmail has been integrated in the maildelivery system
  46.     (i.e. if your system administrator installed it that way, ask him/her),
  47.     then you no longer need the .forward files in your home directory,
  48.     having a .procmailrc file will suffice.
  49.  
  50.     On some systems .forward files are not checked.
  51.     It might be possible that your system supports a command like:
  52.         mail -F "|/usr/bin/procmail"
  53.     to set up forwarding to a program.  (If procmail is in /usr/local/bin
  54.     then use that path instead when trying these.)
  55.     If that doesn't seem to work it might be worth trying to put a line
  56.     looking like this:
  57.         Forward to |/usr/bin/procmail
  58.     or if that doesn't work, try:
  59.         Pipe to /usr/bin/procmail
  60.     as the only line in your mail spool file (e.g. /usr/mail/$LOGNAME), as
  61.     well as doing a "chmod 06660 /usr/mail/$LOGNAME".  For more information
  62.     on such systems, do a "man mail".
  63.  
  64.     If all of this doesn't work, procmail can be called on a periodical
  65.     basis, either via "cron", "at" or whenever you start reading mail (or
  66.     log in).  For a sample script look in the NOTES section of the
  67.     procmail(1) man page.
  68.  
  69. 3. When I compile everything the compiler complains about invalid or illegal
  70.    pointer combinations, but it produces the executables anyway.
  71.    Should I be concerned?
  72.  
  73.     Ignore these warnings, they simply indicate that either your compiler
  74.     or your system include files are not ANSI/POSIX compliant.
  75.     The compiler will produce correct code regardless of these warnings.
  76.  
  77. 4. The compiler seems to issue warnings about "loop not entered at top",
  78.    is that a problem?
  79.  
  80.     No, no problem at all, it just means I wrote the code :-).
  81.     That's just about the only uncommon coding technique I use (don't
  82.     think I don't try to avoid those jumps in loops, it's just that
  83.     sometimes they are the best way to code it).  This warning, as
  84.     well as "statement not reached", can be ignored -- the compiler
  85.     will still generate correct code.  Use gcc if they really bother
  86.     you.
  87.  
  88. 5. The compiler complains about unmodifiable lvalues or assignments to const
  89.    variables.  Now what?
  90.  
  91.     Well, if the compiler produces the executables anyway everything
  92.     probably is all right.    If it doesn't, you might try inserting a
  93.     "#define const" in the autoconf.h file by hand.     However in any case,
  94.     your compiler is broken; I would recommend submitting this as a
  95.     compiler bug to your vendor.  In any case, if this should occur, I'd
  96.     appreciate a mail from you (so I can try to fix the autoconf script
  97.     to recognise your compiler correctly as well).
  98.  
  99. 6. The compiler refuses to compile regexp.c, what is the problem?
  100.  
  101.     Try compiling that module with optimisation turned off.
  102.  
  103. 7. Everything installed just fine, it's just that there are several stale
  104.    _locktst processes which refuse to die.  How do I get rid of those?
  105.  
  106.     In order to prevent things like this from happening to procmail,
  107.     _locktst tries to determine which kernel locking methods are
  108.     reliable.  Sometimes this triggers a bug in the kernel or in
  109.     your system-supplied lockd; this is good, because _locktst detects
  110.     this and makes sure that procmail will not make the same mistake.
  111.     A side effect is that this sometimes leaves behind some stale
  112.     _locktst processes that seem to be unkillable.
  113.  
  114.     This usually is the result of a buggy lockdaemon.  In order to
  115.     get rid of the stale processes, ask your system administrator
  116.     to kill and restart the (rpc.)lockd (and perhaps the (rpc.)statd)
  117.     on both the filesystem-client (where you compiled procmail) and the
  118.     filesystem-server(s) (where the lockingtests took place).
  119.     Depending on the OS it might help if you send the offending
  120.     _locktst processes a kill signal before or after restarting the
  121.     lockd again.
  122.  
  123.     In any case, _locktst just uncovered a bug in your operating system.
  124.     You should contact your system's vendor and ask for a bugfix for
  125.     your lockd.
  126.  
  127. 8. When I send myself a testmail, the mail bounces with the message: cannot
  128.    execute binary file.     What am I doing wrong?
  129.  
  130.     It is very well possible that mail is processed on a different
  131.     machine from that where you usually read your mail.  Therefore you
  132.     have to make sure that procmail has the right binary format to
  133.     execute on those machines on which mail could arrive.  In order to
  134.     get this right you might need to do some .forward file tweaking,
  135.     look at the examples/advanced file for some suggestions.
  136.  
  137. 9. Where do I look for examples about:
  138.     One home directory, several machine architectures?
  139.     Procmail as an integrated local mail delivery agent? (generic,
  140.      sendmail, ZMailer, smail, SysV mailsurr)
  141.     Changing the mail spool directory to $HOME for all users
  142.     Security considerations (when installing procmail suid root)
  143.  
  144.     Well, this probably is your lucky day :-), all these topics are covered
  145.     in the examples/advanced file.
  146.  
  147.     Other examples (e.g. for autoreplies) are most likely to be found by
  148.     typing:        man procmailex
  149.  
  150. 10. How do I use procmail as a general mail filter inside sendmail?
  151.  
  152.     See EXAMPLES section of the procmail(1) man page.
  153.  
  154. 11. Why do I have to insert my login name after the '#' in the .forward or
  155.    .maildelivery file?
  156.  
  157.     Some mailers `optimise' maildelivery and take out duplicates from
  158.     Cc:, Bcc: and alias lists before delivery.  If two or more persons on
  159.     such a list would have identical .forward files, then the mailer will
  160.     eliminate all but one.    Adding a `#' with your login name following
  161.     it will make the .forward files unique, and will ensure that the mailer
  162.     doesn't optimise away some addresses.
  163.  
  164. 12. How do I view the man pages?
  165.  
  166.     If the man(1) program on your system understands the MANPATH
  167.     environment variable, make sure that the installation directory listed
  168.     in the Makefile for the manpages is included in your MANPATH.  If your
  169.     man program does not support MANPATH, make sure that the man pages
  170.     are installed in one of the standard man directories, like under
  171.     /usr/man.  If you do not want to install the man pages before viewing
  172.     them, you can view an individual man file by typing something like:
  173.     nroff -man procmail.1 | more
  174.  
  175. 13. The leading From_ line on all my arriving mail shows the wrong time.
  176.     Before putting procmail in the .forward file everything was OK.
  177.  
  178.     This is a known bug in sendmail-5.65c+IDA.  The real fix would be
  179.     to upgrade to sendmail 6.x or later.  For a quick fix, see the
  180.     procmailex man page.
  181.  
  182. 14. When sending mail to someone with procmail in his/her .forward I sometimes
  183.     get back an error saying: "Cannot mail directly to programs."
  184.  
  185.     This is a known bug in some older sendmails that mistakenly drop
  186.     their root privileges when they are given the -t flag.    Either
  187.     make sure that your sendmail always forwards to a mailserver first or
  188.     upgrade to sendmail 6.x or later.
  189.  
  190. 15. When sending mail to someone with procmail in his/her .forward I sometimes
  191.     get back an error saying:
  192.     "User doesn't have a valid shell for mailing to programs."
  193.  
  194.     This indicates that the mail arrives on a mailserver which most likely
  195.     has a different user database (/etc/passwd) where the login shell
  196.     specified for the recipient is not present in /etc/shells.
  197.     Contact your administrator to put the name of that shell in
  198.     /etc/shells.
  199.  
  200. 16. My mailtool sometimes reports that it is confused about the state of
  201.     the mailbox, or I get "Couldn't unlock" errors from procmail now and then,
  202.     or sometimes it simply seems to hang just when new mail arrives.
  203.  
  204.     This is a known bug in the OpenLook mailtool.  It holds on to the
  205.     kernel lock on the mail-spoolfile most of the time, and releases
  206.     this lock when it shouldn't.  Either ask for a bugfix from your
  207.     vendor (I'm not sure if a bugfix exists), or make sure that during
  208.     the compilation of procmail both the fcntl() and lockf() locking
  209.     methods are disabled (see config.h).
  210.  
  211. 17. I sometimes get these `Lock failure on "/usr/mail/$LOGNAME.lock"' errors
  212.     from procmail.  What do I do about it?
  213.  
  214.     The problem here is that as long as procmail has not read a
  215.     $HOME/.procmailrc file, it can hang on to the sgid mail permission
  216.     (which it needs in order to create a lockfile in /usr/mail).
  217.     I.e. if procmail delivers mail to a user without a $HOME/.procmailrc
  218.     file, procmail *can* (and does) use the /usr/mail/$LOGNAME.lock file.
  219.  
  220.     If, however, it finds a $HOME/.procmailrc file, procmail has to let go
  221.     of the sgid mail permission because otherwise any ordinary user could
  222.     abuse that.
  223.  
  224.     There are several solutions to this problem:
  225.     - Some systems support the sticky bit on directories (when set only
  226.       allows the owner of a file in that directory to rename or remove
  227.       it).    This enables you to make /usr/spool/mail drwxrwxrwt.  It is
  228.       thus effectively world writable, but all the mailboxes in it are
  229.       protected because only the mailbox owner can remove or rename it.
  230.     - If your system did not exhibit the !@#$%^&* POSIX semantics for
  231.       setgid(), procmail would have been able to switch back and forth
  232.       between group mail and the group the recipient belongs to without
  233.       creating security holes.
  234.     - If your system supported setrgid() or setregid() or setresgid()
  235.       with BSD semantics, procmail would have been able to switch...
  236.       (see the previous point).
  237.     - You could simply put the following at the end of your .procmailrc
  238.       file:
  239.  
  240.         LOCKFILE        # removes any preexisting lockfile
  241.         LOG=`lockfile $DEFAULT$LOCKEXT`
  242.         TRAP="rm -f $DEFAULT$LOCKEXT"
  243.             :0
  244.             $DEFAULT
  245.  
  246.     - You could, instead of using /usr/mail/$LOGNAME, use a file below
  247.       your home directory as your default mailbox.
  248.     - Or, you could still use /usr/mail/$LOGNAME as the mailbox, but
  249.       simply instruct procmail to use a different lockfile.     This can
  250.       be achieved by putting following recipe at the bottom of
  251.       your .procmailrc file:
  252.  
  253.         :0:$HOME/.lockmail
  254.         $DEFAULT
  255.  
  256.       You have to make sure that all other programs that update your
  257.       system mailbox will be using the same lockfile of course.
  258.     - You can ignore the problem if you know that both your mail reader
  259.       and procmail use an overlapping kernel locking method.
  260.  
  261. 18. Is procmail Y2K safe/compliant?
  262.  
  263.     Both procmail and formail are Y2K compliant if your system's
  264.     libraries are Y2K compliant.  In particular, they use the
  265.     time_t type to hold the current time when it is needed and
  266.     print out the time using the ctime() library routine.
  267.  
  268.     For those who have examined the code themselves, the casting of
  269.     a time_t value to unsigned long in formail.c is guaranteed to
  270.     work according to the current version of the C language
  271.     standard.  Future revisions of that standard may change that,
  272.     at which time formail will be updated to work with both the new
  273.     and the old standards.
  274.  
  275.     Individual recipes and rcfiles may need to be checked for
  276.     unsafe date handling.
  277.  
  278. 19. How can I make procmail deliver a message to all local users?  E-mail
  279.     for several people all come into a single mailbox and I'm trying to
  280.     split them back up.
  281.  
  282.     If you are asking this, you are on the wrong track.  Procmail
  283.     cannot route messages like this correctly without special help
  284.     from the MTA (sendmail, qmail, etc).  For a more lengthy
  285.     discussion about the issues, please refer to
  286.     http://www.iki.fi/era/procmail/mini-faq.html#advanced
  287.  
  288. 20. None of the above topics cover my problem.    Should I panic?
  289.  
  290.     Let me ask you a question :-), have you examined the CAVEATS, WARNINGS,
  291.     BUGS and NOTES sections of the manual pages *closely* ?
  292.     If you have, well, then panic.    Or, alternatively, you could submit
  293.     your question to the procmail mailinglist (see the man page for the
  294.     exact addresses, or try "procmail -v", or look in the patchlevel.h
  295.     file).
  296.